標籤:物件協作設計
控制反轉容器和依賴注入模式
在 Java 社群中,出現了一波輕量級容器,有助於將不同專案的元件組裝成一個有凝聚力的應用程式。這些容器背後有一個共同的模式,說明它們如何執行配線,這個概念在非常通用的「控制反轉」名稱下被提及。在本文中,我將深入探討這個模式如何運作,使用更具體的「依賴注入」名稱,並將其與服務定位器替代方案進行對比。在它們之間做出選擇,不如將組態與使用分開的原則更為重要。
集合管線
集合管線是一種程式設計模式,您可以在其中將某些運算組織成一系列作業,這些作業透過將一個作業的集合輸出作為下一個作業的輸入來組合。(常見的作業有篩選、對應和簡化。)這個模式在函數式程式設計中很常見,在有 lambda 的物件導向語言中也很常見。本文說明此模式,並提供幾個如何形成管線的範例,既可以向不熟悉此模式的人介紹此模式,也可以幫助人們了解核心概念,以便更輕鬆地從一種語言取得想法並套用至另一種語言。
依賴組成
基於對傳統架構式依賴注入的挫折,我採用了一種組合策略,利用部分應用程式將內容注入模組。當結合測試驅動開發作為設計流程,並專注於函式而非類別時,模組可以保持清晰、乾淨,且大多沒有預期的耦合。
重構:此類別太大
在本文中,我將逐步說明一組來自實際程式碼庫的重構。這並非要展示完美,而是代表現實。
重構存取外部服務的程式碼
當我撰寫處理外部服務的程式碼時,我發現將存取程式碼分隔成不同的物件很有價值。在此,我將展示如何將一些凝結的程式碼重構成這種分隔的常見模式。
使用迴圈和集合管線進行重構
迴圈是處理集合的經典方式,但隨著程式語言中一級函式的採用程度提高,集合管線是一種有吸引力的替代方案。在本文中,我將透過一系列小範例來探討將迴圈重構成集合管線。
DIP 在實際應用中
依賴反轉原則 (DIP) 自 90 年代初期就已存在,即使如此,在解決問題的過程中似乎很容易忘記它。在一些定義之後,我將展示我在實際專案中親自使用過的多個 DIP 應用,這樣你將有一些範例可以形成自己的結論。
D D D_ 聚合
聚合是領域驅動設計中的模式。DDD 聚合是可視為單一單位的領域物件叢集。範例可能是訂單及其品項,這些將會是個別的物件,但將訂單(連同其品項)視為單一聚合是有用的。
內嵌文件
我發現最近越來越多人透過伺服器傳遞 JSON 資料結構。JSON 文件可以直接儲存,方法是使用 AggregateOrientedDatabase 或關聯式資料庫中的 序列化 LOB。JSON 文件也可以直接提供給網路瀏覽器或用於將資料傳輸到伺服器端頁面渲染器。當 JSON 以這種方式使用時,我聽見有人說使用物件導向語言會造成阻礙,因為 JSON 需要轉譯成物件才能再次渲染出來,這浪費了程式設計的功夫。我同意浪費這一點,但我認為這不是物件的問題,而是不了解封裝。
函式作為物件
在程式設計中,物件的基本概念是資料和行為的組合。這在撰寫一組相關函式時提供了常見的資料內容。它也提供了操作資料的介面,讓物件可以控制對該資料的存取,使其容易支援衍生資料並防止資料無效修改。許多語言提供明確的語法來定義類別,這些類別充當物件的定義。但是,如果你有一個具有第一類函式和封閉的語言,你可以使用這些建構來使用函式作為物件模式(最初由 Eugene Wallingford 描述)建立物件。
Getter 消滅者
你可以從他們看到 getter 方法時嘴角左邊抽搐看出,他們迅速拔出戰斧,並在另一個 getter 無情地從一個類別中砍下時發出滿足的叫聲,而這個類別立即在男子氣概的 Getter 消滅者腳下昏厥,感激不已。
介面實作配對
將每個類別與介面配對的做法。因此,你會看到成對的事物,可能是 ICustomer 和 Customer 或 Customer 和 CustomerImpl。在許多方面,它呼應了 C/C++ 為每個類別建立標頭檔的習慣,儘管在這種情況下,介面和實作實際上是不同的類型。
控制反轉
控制反轉是你擴充框架時會遇到的常見現象。事實上,它通常被視為框架的定義特徵。
延遲初始化
延遲初始化是一種在第一次存取時初始化變數(在 OO 背景中通常是類別的欄位)的技術。它的正規形式類似這樣
所需介面
所需介面是由互動客戶端定義的介面,它指定供應元件需要執行哪些動作才能在該互動中使用。
告訴,不要詢問
告訴,不要詢問是一項原則,可幫助人們記住物件導向是關於將資料與運作該資料的函式綑綁在一起。它提醒我們,不要詢問物件資料並對該資料執行動作,而是應該告訴物件要執行什麼動作。這鼓勵將行為移入物件中,以搭配資料。